Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed some flashing issues on STM32L0 #1330

Merged

Conversation

andars
Copy link
Contributor

@andars andars commented Aug 27, 2023

Hi,

While trying to use st-link to flash a STM32L051 on a custom board, the flash loader fails in stm32l1_write_half_pages, and the fallback path usually reports "Flash memory contains a non-erased value" (but still successfully writes the flash since the NOTZEROERR doesn't prevent the write on this category 3 device - 3.3.4 RM0377). So st-flash write does write the flash but reports failure, and load in gdb using st-util server reports Error finishing flash operation.

I found two issues in the flashing code:

  • stm32l1_write_half_pages calls stlink_flash_loader_run with a local flash_loader_t struct that is never initialized, so the loader is run using uninitialized values for the loader code base address and the SRAM buffer address
  • loader_code_stm32lx is used for both STM32L0 devices with armv6-m cores and STM32L1 devices with armv7-m, but it uses add instructions that are only supported in armv7-m, so when loader code runs it writes one word to flash and then faults on the add.

With these issues fixed, flashing works without error on this device.

This is related to the various reported issues about failures flashing STM32Lx devices (e.g. in #681) and probably helps fix some of those, but I don't have other hardware to test on to confirm if this improves things on devices other than STM32L051. Based on the code history these 2 bugs seem to be introduced more recently than some of the early reported issues, so there may be some remaining issues too.

It seems like the current flashloader implementation in stm32l1_write_half_pages maybe doesn't have much advantage over the fallback path using stlink_write_mem32 since both wait for flash programming to complete from the host system every halfpage, but these 2 commits make this path work for now on in my testing on STM32L051
( in the future it can potentially be enhanced to poll on FLASH_SR_BSY every halfpage from the device instead of the host or removed if not useful)

(Closes #681) (Closes #1203) (Closes #1225) (Closes #1253) (Closes #1289)

stm32l1_write_half_pages uses a local flash_loader_t that is never
initialized.

This results in stlink_flash_loader_run using uninitialized values for
fl->buf_addr and fl->loader_addr when copying the buffer
and initializing the source register and PC before running the core to
execute the flashloader.

Pass the flash_loader_t from stlink_flashloader_write through to
stm32l1_write_half_pages and use that one instead of an uninitialized
local structure.
STM32L0 chips use loader_code_stm32lx, but this flash loader is built
for armv7-m and uses instructions that are unsupported on STM32L0 (which
have Cortex M0+ cores implementing armv6-m).

In particular, loader_code_stm32lx uses variants of add-immediate that
do not update the condition flags ( `add r0, r0, stlink-org#4` ). These are 32bit
instructions in armv7-m and are not available in armv6-m.

Enable loader_code_stm32lx to run on both armv6-m and armv7-m by
building for armv6-m, which requires changing the `add` instructions to
`adds` instructions that do update condition flags (which is ok because
the subs updates the condition flags again before the branch).
@Nightwalker-87
Copy link
Member

Now we need to identify the related issues that are addressed by this fix.

@Nightwalker-87 Nightwalker-87 changed the title Fix some flashing issues on STM32L0 Fixed some flashing issues on STM32L0 Aug 27, 2023
@Ant-ON
Copy link
Collaborator

Ant-ON commented Aug 28, 2023

@Nightwalker-87 I think this most likely should fix #1203, #1289, #1253

@Nightwalker-87 Nightwalker-87 merged commit f3fcaf2 into stlink-org:develop Sep 1, 2023
10 checks passed
@stlink-org stlink-org locked as resolved and limited conversation to collaborators Sep 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.